home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0185.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  3.6 KB  |  70 lines

  1. I am replying very late to a message of Frank Kappe,
  2. dated 25 Jun 1992.
  3.  
  4. First of all, to clear up some things about W3 HTML.
  5. You can't nest anchors.
  6. You can't nest anything EXCEPT you can put any elements inside
  7. an anchor (excpt for other anchors) and you can put an anchor
  8. inside any elements.
  9. Then there is the slight structure of the <DL>[<DT><DD>]*</DL>
  10. etc which is required.
  11.  
  12. I think I emntioned in earlier messages that the lack of structure
  13. is to make it easier to process HTML on systems which have styled
  14. text (like most systems, MSWord etc).
  15.  
  16. Now it is interesting that you in Gyper-G allow anchors to be
  17. any section of the text.  This of course is counter to the
  18. SGML philosophy of strict nesting (SGML people can get quite
  19. religeous about this, but I can't.)  I think it is useful
  20. to be able to refer to two separate overlapping anchors.
  21. The problem is it is taken as given by any SGML DTD designer
  22. that this sort of structure in a document is "BAD". This
  23. means that SGML tools won't be able to process the <AS>
  24. and <AE> (anchor start and anchor end) tags, you'll have to
  25. write something special on top which keep track of anchors.
  26. AGML parsers won't be able to verify the anchor structure.
  27. So though the DTD is valid, but it doesn't in fact representthe restrictions.
  28.  
  29. You say that you feel it is better to store the links separately
  30. rather than in the document.  First of all let me say that W3 does NOT
  31. require you to do that -- it just requires that the links, anchors
  32. and text are transmitted at the same time on the net. That is very different.
  33. Many systems generate the HTML on the fly from other sources of link
  34. information.
  35.  
  36. Nowlooking at this question of where to store the links, the 'link database"
  37. model you propose is the Intermedia model of Norman Meyrowitz et al.
  38. This was developped in a non-distributed environment, where a "web"
  39. (database of links) was available to the readers and centrally coordinated.
  40. If you expand that system to more than one web server, and scale it to
  41. global, then you find that the same problems of ensuring consistency
  42. occur between the multiple link databases when before they occured between dcouments.  You can't set up a system of bidirectional links for example,
  43. which you could in the non-distributed case.
  44.  
  45. Link databases have their advantages, though.  A model I am rather keen on
  46. atthe moment is of servers which are both link databases and
  47. source code control (sccs, rcs etc) systems.  In this world,
  48. you don't need to store anchors at all -- you just quote the
  49. character number AND VERSION number of the document.  To find an
  50. anchor, if you have a more recent version than the one referred to in the anchor,
  51. you have to ask the server to translate the anchor's position in the
  52. old document into a position in the new one. It may reply with
  53. the same or a didfferent position, or that as far as its "diff"
  54. algorithms go, it can't find where the original anchor text would
  55. be in the new document, or it might really have gone.
  56. This would allow links to be made around source code (for which you want
  57. source code control anyway).
  58.  
  59. There would be common problems when you do the sorts of changes which
  60. diff can't handle intelligently, like you swap the two halves of a file,
  61. or you change all the "a_"s to "A_".  In these cases, a smart editor
  62. would be able to explian each editing change to the server as it goes,
  63. to the server would understand the relationship between the pre-edit
  64. and post-edit versions.  If you are going to do that, then you can
  65. go a small extra step and make the server coordinate simultaneous edits
  66. by many people, which gives you a group editor.
  67.  
  68.    Tim
  69.  
  70.